Some refactorings around metadata encoding - #162900

r? @Zalathar , for example, I've seen you refactoring the metadata infra recently

Zalathar is not on the review rotation at the moment.
They may take a while to respond.

Could you explain more about proc_macro_quoted_spans and why it's being moved?

From the PR description and commit message, I wasn't able to get a good sense of why this change is desirable, or whether it's even correct.

Could you explain more about proc_macro_quoted_spans and why it's being moved?

It was the only table that has usize as key, so we can't use macros to record values in it, and values in this table are set only under is_proc_macro condition in encode_proc_macros, so if ProcMacroData is None (meaning is_proc_macro is false) then all queries to this table will panic, so we can move this table into ProcMacroData, I thought that it is more appropriate place for this table.

So if I understand correctly:

• proc_macro_quoted_spans is only used in proc-macro crates, and ProcMacroData is specifically for holding data that is only used in proc-macro crates. So moving it to ProcMacroData is a reasonable change, regardless of why we want to move it out of LazyTables.
• The reason we want to move it out of LazyTables is that it's the only one of those tables with a key type that isn't DefIndex. So having proc_macro_quoted_spans in LazyTables is getting in the way of changes to how DefIndex is treated.
• The fact that proc_macro_quoted_spans happens to have a key type of usize is irrelevant, and prominently mentioning usize is misleading to future maintainers.

If so, could you please update the commit message and PR description to clearly explain the reasoning to future maintainers, and remove the misleading stuff about usize?